-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat(nuxt): Instrument storage API #17858
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(nuxt): Instrument storage API #17858
Conversation
07cb542
to
24a5470
Compare
a6dc41f
to
fe203a5
Compare
911b7fe
to
abe38de
Compare
64e5814
to
42ef2c7
Compare
size-limit report 📦
|
node-overhead report 🧳Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
|
83bb4e8
to
f5cd0ca
Compare
83e35f8
to
d621605
Compare
if (CACHE_HIT_METHODS.has(methodName)) { | ||
span.setAttribute(SEMANTIC_ATTRIBUTE_CACHE_HIT, !isEmptyValue(result)); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if we should always treat data retrieval as a cache hit 🤔 This also adds this attribute even though it's not specifically set up as a Nitro cache, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I figured KVs as a low latency storage are being used primarily as a cache, I don't think we can infer the user intention here.
Given that it can expire via TTL, I thought to treat it as cache.
I don't have a strong opinion, what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, all good to go. Just some comments
Adds [Nitro/Nuxt Cache API](https://nitro.build/guide/cache) instrumentation by building upon the storage instrumentation in #17858 since both use `unstorage` under the hood. #### How it works Nitro injects the cache storage on either `cache:` or the root mount depending on user configuration, also in production the `cache` storage is placed on the root mount unless the user configures it explicitly to redis or something else. We instrument both mount drivers to cover other cache use cases. --- I made sure to add e2e tests as well for `cachedEventListner` and `cachedFunction` calls which are the main ways to use the Cache API. This PR depends on the storage PR #17858. --------- Co-authored-by: Sigrid Huemer <32902192+s1gr1d@users.noreply.github.com>
This pull request introduces automatic instrumentation for database queries in Nuxt applications in server side handlers using Sentry. #### Implementation Details - Instruments database `.sql`, `.prepare` and `.exec` calls. - Adds breadcrumbs and spans following cloudflare's D1 implementation. This relies on the work done in #17858 and #17886
What
This PR adds automatic instrumentation for Nuxt's storage layer (powered by unstorage), enabling performance monitoring for cache and key-value storage operations in Nuxt/Nitro applications.
Storage operations will now automatically create performance spans with detailed attributes for observability in Sentry.
What's New
nuxt.config.ts
vianitro.storage
getItem
,setItem
,hasItem
,removeItem
getItemRaw
,setItemRaw
getItems
,setItems
getKeys
,clear
get
,set
,has
,del
,remove
Implementation Details
Span Attributes:
sentry.op
:cache.{operation}
(e.g.,cache.get_item
,cache.set_item
)sentry.origin
:auto.cache.nuxt
cache.key
: Full key including mount prefixcache.hit
:true
for successful get/has operationsdb.operation.name
: Original method namedb.collection.name
: Storage mount pointdb.system.name
: Driver name (e.g.,memory
,fs
,redis
)Files Changed:
packages/nuxt/src/runtime/plugins/storage.server.ts
- Runtime instrumentation pluginpackages/nuxt/src/vite/storageConfig.ts
- Build-time configurationpackages/nuxt/src/module.ts
- Module integration